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REMARKS 

Claims 1 and 3-4 have been rejected under 35 U.S.C. § 103(a) as being unpatentable 
over Croslin, further in view of Beurket et ai., further in view of Swildens et al., U.S. Patent No, 
6,484,143. Claim 2 has been rejected under 35 U.S.C. § 103(a) as being unpatentable over 
CrosHn, further irfview of Beurket el a!, and Swildens et al., further in view of Guentlmer et al., 
U.S. Patent No. 6,360,262. Claims 5-7 were rejected "for similar reasons." 

Respectfully, these rejections are traversed. 

In considering the most recent rejection, Croslin is said to teach "a method of mapping 

the Internet to generate an optimized set of proxy points in a local name server address space " in 

part by "executing a rouf*^ over the Internet from each data center to a given local name server " 

^ 

This is not the case. In particular, each pending claim concerns testing an actual network with 
respect to an Internet "name server." Claim 1 emphasi^es this, e.g., by reference to "a local 
name server address space" and executing trace routes "to a given local name server." Likewise, 
claim 5 refers to "end user local name server requests" in the preamble and requires that the 
routes are physically traced fi-om each mirror site "to the local name server." Claim 7 states that 
the "client requestV^s a "client^name server request," and this claim also states that the routes 
being run intersect at a "given name server." Croslin, which concem^voice/data 
telecommunications network, says nothing about Internet name ser\'ers, name server address 
space maps, name server locations, trace routing to name servers, or the like. These "name 
server" limitations in each claim are meaningful, and they are neither disclosed nor suggested in 
Croslin. 

Further, as previously pointed out, the present invention involves physical probing of 
physical devices on a network to generate relevant data; the portions of Croslin relied upon by 
the Examiner involve software-driven analysis of a database table that allegedly illustrates a set 
of physical telecommunications links. Thus, in the present invention, a relevant method step 
calls for physical acts to take place over a physical network; at most, Croslin simply teaches - 
analyzing a "representation" of a physical network, not performing the relevant tests on the 
physical network itself. Moreover, the representation in Croslin has nothing to do with a "local 
name server address space" let alone "executing a route over the Internet from [each] data center 
to a given local name server." 
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As previously noted, the claims describe this physical probing to physical name ser\'ers 
explicitly: 

"for a given pair of data centers each accessible over the Internet, physically executing a 
trace route over the Internet from each data center to a given local nairre sei-ver" (claim 1 ) 

"for each local name server, physically directing a trace route over the public Internet 
from each content provider mirror site to the local name server" (claim 5); 

Lidependent claim 7 is even more specific about the physical probing: 

"dynamically determining a set of proxy points, wherein each proxy point of the set of 
proxy points is determined by physically directing a trace route over the public Internet from 
each Qf the set of mirror sites towaid a given name server and determining a given point in the 
public Internet where the trace routes from each of the set of mirror sites intersect.'' ^ 

The above-cited claim limitations illustrate the physical nature of the method step at issue 
and further emphasize that the steps are taken with respect to given name servers : these aspects 
of the present invention are completely absent from Croslin. 

In particular, Croslin simply describes a system 200 diat runs a restoration process 208, 
which is a software routine. The process 208 reads and writes data from a restoration database 
, 212. This data incMes a series of tables that represent the network tggplogy and are used to 
develop the restoration routes. As described in Figure 5, there are a s'^ls of steps perfomied to 
generate a restoral route for a given impacted trunk of the telecommu^cations network. 
Initially, an "intersection table" is built that identifies instances where a sub-route that originates 
from a given "lefthand" node intersects (i.e. shares at least one common node) with a sub-route 
that originates from a "righthand" node. A lefthand node is one diat lies to the left of the 
network outage and a righthand node is one that lies to the right of the network outage. 
According to the patent, the lefthand node is "folded out" to identify from the sub-route table all 
nodes that are end nodes from a sub-route that begins from the node being folded out. Once the 
intersection table (see Figure 10) for the impacted trunk is generated, the table can be read to 
determine the restoral route. In particular, the restoration process 208 checks whether an ^ 
intersection is found in the intersection table. If so, an optimal intersection route is selected, and 
this is typically the route with the lowest cost. The selection of the route constitutes a selection 
or combination of the two end node pairs Uiat intersect, as indicated by the data in the table. 
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The written description of the present invention relates to a technique for generating a 
network map for a user-base of the Internet, histead of probing each local name server that is 
connectable to a mirrored data center, however, the network map identifies connectivity with 
respect to a much smaller set of points, referred to in the application as "core" or "common" 
points. Each set of mirrored data centers preferably has an associated map that identifies a set of 
core points. In one embodiment, die core points are identified using an incremental trace route 
that is physically executed (i.e., run) from each of the set of mirrored data centers to a local name 
server . A "trace route" (or "traceroute") is a computer network test used to detennine the route 
taken by data packets across an actual IP network. This is a real test carried out on a real 
network with respect to a real name server, not simply a software instruction executed against a 
database representation, as in Croslin. An intersection of the trace routes at a common routing 
point is then identified. The core point discovery process is illustrated in Figure 3. Preferably, 
the trace routes are between data centers and local name servers . The core points are the 
intersection point of a trace route or near or substantially near the intersection point. 

Unlike the present invention, Croslin does not locate intersection points utilizing trace 
routes performed on the actual Internet. Croslin builds sub-route tables based upon nodes 
identified by topold'yj^ data. Points aie identified from these database tables, and not from a trace 
route that is actually performed in a network being mapped. 

Neither Buerket et aL nor Guenthner et al., two of the secondly references, make up for 
the deficiencies in Croslin. In particular, neither reference discloses (nor does the Examiner say 
othenvise) the physical probing of a physical network to facilitate generation of a proxy point 
map according to the present invention. 

Swildens et al., the newly-cited reference, is of general interest to the present invention 
(and it is commonly-owned by the assignee of this application). While this patent teaches global 
load balancing across mirrored origin sites and the use of trace routing, the subject claims are 
very specific to a map making method that is neither disclosed nor remotely suggested by 
Swildens et al. 

Under Section 1 03, it is tlie subject matter "as a whole" that must be considered for 
patentability. Even if the references could be combined in the manner proposed by the 
Examiner, at least the following limitations are absent: 

-6- 

PAGE 11/12 * RCVD AT 12/26/2000 12:32:03 PM [Eastern Standard Time] * 8VR:USPTO-EFXRF-3/16 * DNI8:2738300 ' C8)D:g72 3S3 2023 * DURATION (mm-ss): 06-30 



Dec 2G OB 11:40a 



972-385-2023 



p. 12 



"for a given pair of data centers each accessible over tlie Internet, physicatly executing a 
trace route over the Internet from each data center to a given local name server " (claim 1) 

"for each local name server, physically directing a trace route over the pubh'c Internet 
from each content provider mirror site to the local name server " (claim 5); 

"dynamically determining a set of proxy points, wherein each proxy point of the set of 
proxy points is determined by physically directing a trace route over the public Internet from 
each of th e set of mirror sites toward a given name seiT/er and determiaing a given point in the 
public Internet where the trace routes from each of the set of mirror sites intersect (claim 7) 

To further emphasize that the method of the present invention is associated with building 
a name server map, each independent claim has been amended to further clarify that the namej^ 
server is one of a plurality of name servers that clients use to access resoiurces on the Internet. 
This language is not required in view of the prior art but is added to provide additional clarity as 
to the particular environment in which the inventive method is designed to operate. 

All claims should be allowed, and a notice to that effect is respectfully requested. 
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